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METHOD AND APPARATUS FOR EFFICIENT 
ROUTING OF MOBILE NODE PACKETS 

BACKGROUND 

Field of the Invention 

This invention relates to mobile nodes or devices, and more specifically to 
efficient routing of packets of mobile nodes. 
Background Information 

Wireless access to the Internet is becoming more and more popular. 
Wireless devices used to access the Internet include, for example, mobile phones, 
personal digital assistants (PDA), and notebook computers. Mobile IP is an 
emerging set of extensions to the Internet Protocol (IP) for packet data transmission. 
This allows wireless devices (mobile nodes) to roam without continually changing the 
wireless device's IP addresses and reinitializing sessions. 

The IP protocol routes packets to their destinations according to IP 
addresses. These addresses are normally associated with a fixed network location. 
When a packet origination or destination is a mobile node, each new point of 
attachment to the network made by a mobile node is associated with a new IP 
address. In mobile IP, when a mobile node moves to a village network (subnetwork 
outside of the mobile node's home subnetwork), the mobile node gets assigned a 
temporary address known as a Care of Address (CoA). The CoA changes at each 
new point of attachment by the mobile node. After a mobile node gets a CoA, the 
mobile node uses this care of address as the source IP address for its packets. 

Many flows (i.e., set of packets with a common source address and 
destination address) only require a best effort class of quality of service (QoS). 
These type flows may not require strict bandwidth, delay, or other requirements. 
However, flows that carry IP packets comprising multimedia streams such as video 
conferencing may demand a higher level of quality of service. Therefore, it is 
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important that mobile IP be interoperable with protocols that provide real time 
services in the Internet. 

Resource reservation protocol (RSVP) is a protocol designed for an integrated 
services Internet. The RSVP protocol may be used by an originating node to request 
specific qualities of service from the network for particular application data streams 
or flows. RSVP may also be used by routers to deliver quality of sen/ice requests to 
all nodes along the paths of the flows and to establish and maintain state to provide 
the requested service. RSVP requests generally result In resources being reserved 
in each RVSP node (i.e., RSVP router) along the data path of the flow. 

A RSVP reservation is based on a "flow spec" and a "filter spec". The flow 
spec specifies a desired QoS, while the filter spec is used to set parameters in the 
packet classifier. In order to provide the appropriate desired QoS to a flow, a RSVP 
packet classifier selects data packets based on the filter spec which uses the sender 
IP address as one of the parameters and optionally the UDP/TCP port number. 

When an RSVP node receives a flow containing one or more packets, the 
RSVP node tries to identify the packet based on the source (i.e., sender) IP address. 
For a mobile node that has moved from its home location, this source IP address will 
consist of the care of address in the IP header. When a channel is initially set up to 
carry a flow between a mobile node and a second node (e.g., correspondent node), 
the channel (i.e., path) is set up based on a home IP address of the mobile node, not 
the care of address. The home address tells RSVP routers that exist in the path, 
between the source and destination points of the flow, whether the packets get 
previously reserved resources associated with a flow from the home address. RSVP 
nodes only know home address and not care of address. Therefore, when an RSVP 
node processes packets as currently defined today, the original packet classifier 
does not recognize the flow from a relocated mobile node because the particular 
session (represented now by the care of address) will not match any of the filter 
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specs (that contain the home address). Thus, the classifier cannot provide the 
desired QoS since routers on the path of the relevant traffic flows are not able to 
classify these packets correctly. The reserved resources will be wasted, and the 
flow will instead be handled as best effort traffic. 

Moreover, using the current RSVP specification, a new end-to-end RSVP 
reservation procedure needs to be performed in order to maintain the same QoS 
after the mobile node has obtained a new care of address. This is not realistic and 
inefficient for real time applications because the traffic (flow) sent while the end-to- 
end reservation procedure takes place can only obtain best effort treatment. Current 
methods use the care of address for flow identification, however, the care of address 
can change rapidly during a flows lifetime, therefore, making this method also 
problematic. 

Another problem arises when a mobile node changes its point of attachment 
and performs handoff. In the uplink direction, a mobile node can reissue a path 
message, which causes a RESV message to be sent from a crossover router (i.e., a 
router which lies in both the old and new path from a mobile node to a correspondent 
node). However, the reservation on the old path between the crossover router and 
the mobile node's former point of attachment remains in place until the reservation 
state for this path times out. This is problematic, especially when considering that a 
mobile node can change its point of attachment very frequently. 

Another problem is that the old care of address of a mobile node may be 
reused after it changes its point of attachment to the Internet. This may imply that if 
reservations are identified based on the care of address, another node could benefit 
from a reservation which has not been removed and which has also not timed out 
yet. 

A further problem with current systems is that if sessions are identified based 
on the care of address, it is necessary to set up fully new RSVP sessions after a 
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mobile node receives a new care of address instead of just updating the existing 
sessions. In the worst case, this could mean that a session which still exists for a 
mobile node's old care of address (i.e., a session which has not timed out yet) could 
block the establishment of the session for the new care of address, even though both 
sessions are meant to handle the same traffic flow. 

Moreover, a problem exists in that in order for RSVP daemon in a 
correspondent node to obtain the care of address of the mobile node, mobile IP 
needs to provide an interface to reveal the care of address of the mobile node, which 
could also be used by any other application. This violates the location privacy 
requirement. 

A further problem exists in that it is also necessary to always negotiate the 
new RSVP sessions all the way between a mobile node and a correspondent node. 
This precludes optimized solutions where it would be possible to only set up the path 
between the mobile node and the crossover router. 

In addition, current methods of handoffs when a mobile node moves to 
another point of attachment are inefficient. Currently, when a mobile node moves to 
another point of attachment, the mobile node sends a binding update to the 
correspondent node. However, the correspondent node does not act upon it 
immediately. Therefore, the path between the crossover router and the mobile node 
does not receive the proper QoS until the next PATH refresh message. Additionally, 
if a mobile node sends a RESV refresh message before the next PATH refresh 
message, the mobile node receives a error message because the routers on the 
path between the mobile node and crossover router are not aware of the RSVP 
session yet. An immediate solution to this problem may be to trigger a PATH refresh 
at the correspondent node when the binding update is received. However, this 
implies that it takes one and one half round trips between the mobile node and the 
correspondent node to set up the QoS on the path between the mobile node and 



017.39656X00 
17221 

crossover router (which may be a very short path as compared to the path between 
the mobile node and correspondent node). This mechanism is highly inefficient. 

Therefore, there is a need for efficient routing of mobile node packets, 
specifically when RSVP is used in mobile IP nodes. 

5 

SUMMARY 

; The present invention is directed to a method for efficient use of resource 

reservation protocol (RSVP) in mobile Internet Protocol (IP) nodes that includes: 
" configuring a classification function at each RSVP router to classify a received flow 

10 ' based upon a home address option in a destination option header of an IP pacl<et in 
the flow if the address is present; moving a mobile node from a first subnetwork 
location to a second subnetwork location, where the second subnetwork location is 
outside a home address subnetwork of the mobile node; sending a configuration 
message from the mobile node along a path to a second node; sending a 

15 confirmation message from the second node along the path to the mobile node, 

where the confirmation message reserves resources in RSVP routers in the path for 
a flow from the mobile mode; sending the flow containing at least one IP packet from 
the mobile node to the second node along the path, where each at least one packet 
has a temporary source address in a source address field of a IP header of each at 

20 least one IP packet and the home address of the mobile device in the destination 
option header of each at least one IP packet; classifying the flow by each RSVP 
router in the path based on the destination option header; and routing the flow by 
each RSVP router in the path, where each RSVP router in the path uses the 
reserved resources associated with the flow based on the classification. 

25 The mobile node may be a mobile phone. The second node may be a phone. 

The temporary source address may be a Care of Address (CoA). The first 
subnetwork may be a first IP subnet and the second subnetwork may be a second IP 
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subnet. The home address may be an IP address. The configuration message may 
be a PATH message. The confirmation message may be a RESV message. 

The method may further include: moving the mobile node from the second 
subnetwork location to a third subnetwork location; sending a second configuration 
message from the mobile node to a crossover RSVP router in the path, where the 
second configuration message is sent along a second path from the mobile node to 
the crossover RSVP router; sending a second confirmation message from the 
crossover RSVP router to the mobile node, where the second confirmation message 
reserves resources in RSVP routers in the second path for the flow from the mobile 
mode; and sending the flow from the mobile node to the second node along the 
second path between the mobile node and the crossover RSVP router and the path 
between the crossover RSVP router and the second node. 

The method may further include sending a teardown message from the 
crossover RSVP router to a RSVP router in the path that is not between the 
crossover RSVP router and the second node, where the teardown message is 
propagated to all other RSVP routers in the path that are not between the crossover 
RSVP router and the second node. The teardown message may cause each RSVP 
router in the path that is not between the crossover RSVP router and the second 
node to release the reserved resources for the flow from the mobile mode. The 
teardown message may be a RESVTEAR message. 

The present invention is further directed to an article comprising a storage 
medium having instructions stored therein, the instructions when processed causing 
a RSVP router to perform: receiving configuration information that configures the 
RSVP router to classify a received flow based upon an address in a destination 
option header of an IP packet in the flow if the address is present; reserving 
resources in the RSVP router for a flow based on receipt of a message; receiving the 
flow, where the flow contains at least one IP packet; classifying the flow by the RSVP 
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router based on the destination option lieader In eacli at least one IP packet; and 
routing the flow by the RSVP router, where the routing uses the reserved resources 
associated with the flow based on the classification. 

The instructions may further cause: receiving a second message; propagating 
the second message to other RSVP routers if appropriate; and releasing the 
reserved resources for the flow In response to the second message. 

The present Invention is also directed to a network that Includes: at least one 
first node; at least one second node; and at least one RSVP router, where each at 
least one RSVP router is configured to classify a received flow based upon a home 
address option in a destination option header in IP packets in the flow if the address 
is present. One at least one first node sends a flow comprising at least one IP 
packet to one at least one second node. At least one RSVP router reserves 
resources in the router for the flow based on receipt of a previous message. The at 
least one RSVP router classifys the flow based on the destination option header in 
each at least one IP packet, and routes the flow using the reserved resources 
associated with the flow based on the classification. 

Moreover, the present Invention is directed to a RSVP router that includes:a 
reservation module, where the reservation module reserves resources for a flow in 
response to receipt of a message from a second node; a receiving module, where 
the receiving module receives the flow consisting of at least one IP packet, and 
where the flow originates at a first node and having a destination of the second node; 
a classification module, where the classification module classifies the received flow 
based upon a home address option in a destination option header in the at least one 
IP packet in the flow if the address Is present; and a routing module, where the 
routing module routes the received flow using the reserved resources associated 
with the flow based on the classification. 
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The present invention is additionally directed to a method for efficient handoff 
during use of resource reservation protocol (RSVP) in mobile internet Protocol (IP) 
nodes that includes: sending a flow containing one or more IP pacl<ets from a mobile 
node in a first subnetwork location to a second node along a first path, where at least 

5 one RSVP router is in the first path between the mobile node and the second node; 
moving the mobile node from the first subnetwork location to a second subnetwork 
location; sending a first message from the mobile node along a second path to the 
second node, where the second path includes one of the at least one RSVP routers 
in the first path, and a portion of the first path between the one at least one RSVP 

10 router and the second node is part of the second path; sending a second message 

from the mobile node to second node or the one at least one RSVP router, where the 
second message triggers the sending of a third message from the second node or 
the one at least one RSVP router to the mobile node; sending a fourth message from 
the one at least one RSVP router to the at least one RSVP router in the first path that 

15 is not part of the portion of the first path between the one at least one RSVP router 
and the second node, where the fourth message removes reservations for the flow; 
and receiving the third message by the mobile node and sending a fifth message 
from the mobile node to the one at least one RSVP router, where the fifth message 
reserves resources for the flow in each RSVP router in the second path between the 

20 one at least one RSVP router and the mobile node. 

The mobile node may be a mobile phone. The second node may be a phone. 
The first message may be a binding update message. The second message may be 
a care of address advertisement RSVP message. The third message may be a 
PATH message. The fourth message may be a RESVTEAR message. The fifth 

25 message may be a RESV message. The third message may be sent from the one 
at least one RSVP router to the second node. 
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The present invention is further described in the detailed description which 
follows in reference to the noted plurality of drawings by way of non-limiting 
examples of embodiments of the present invention In which like reference numerals 
represent similar parts throughout the several views of the drawings and wherein: 

Fig. 1 is a block diagram of an example RSVP node according to an example 
embodiment of the present invention; 

Fig. 2 is a diagram of a network where a mobile node is moved according to 
an example embodiment of the present invention; 

Fig. 3 is a diagram of a network during tear down of an old path according to 
an example embodiment of the present invention; and 

Fig. 4 is a diagram of a network with efficient handoffs according to an 
example embodiment of the present invention. 

DETAILED DESCRIPTION 

The particulars shown herein are by way of example and for purposes of 
illustrative discussion of the embodiments of the present invention. The description 
taken with the drawings make it apparent to those skilled in the art how the present 
invention may be embodied in practice. 

Further, arrangements may be shown in block diagram form In order to avoid 
obscuring the invention, and also In view of the fact that specifics with respect to 
implementation of such block diagram arrangements is highly dependent upon the 
platform within which the present Invention is to be implemented, i.e., specifics 
should be well within purview of one skilled in the art. Where specific details (e.g., 
circuits, flowcharts) are set forth in order to describe example embodiments of the 
invention, it should be apparent to one skilled in the art that the invention can be 
practiced without these specific details. Finally, it should be apparent that any 
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combination of hard-wired circuitry and software instructions can be used to 
implement embodiments of the present invention, i.e., the present invention is not 
limited to any specific combination of hardware circuitry and software instructions. 

Although example embodiments of the present invention may be described 
using an example system block diagram in an example host unit environment, 
practice of the invention is not limited thereto, i.e., the invention may be able to be 
practiced with other types of systems, and in other types of environments (e.g., 
servers). 

Reference in the specification to "one embodiment" or "an embodiment" 
means that a particular feature, structure, or characteristic described in connection 
with the embodiment is included in at least one embodiment of the invention. The 
appearances of the phrase "in one embodiment" in various places in the specification 
are not necessarily all referring to the same embodiment. 

The present invention relates to efficient routing of mobile node packets. To 
illustrate the present invention, IP packets and network along with RSVP nodes 
(routers) will be used. However, the present is not limited to RSVP routers or IP 
packets. Any type nodes, protocols, networks, etc. that perform efficient routing of 
mobile node packets as illustrated herein are within the spirit and scope of the 
present invention. Using RSVP and IP as example embodiments, according to the 
present, RSVP nodes check a destination option header to determine if it contains a 
home address option of the mobile node. If the home address option is present, the 
RSVP node uses the home address of the mobile node to perform classification, 
otherwise the RSVP node uses the source IP address as ususal. According to the 
mobile Internet protocol, version 6 (IPv6) specification, a home address option must 
be included in clear text in the destination option header of every IP packet when 
mobile IP is used. In the presence of the home address option, the filter spec sent 
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by the sender should include the home address of the sender and optionally the 
UDP/TCP port nunnber source port. 

Therefore, in methods and apparatus according to the present invention, 
whenever a RSVP node receives an IP packet, the destination option header is 
checked first. Moreover, when the mobile node moves to another serving system, a 
new message (e.g., PATH message) may be sent by the mobile node, but this 
message only propagates upstream (along the new path) until it reaches a 
crossover point where an existing reservation already exists. The crossover point 
may be a crossover RSVP router that does not forward the PATH message further 
upstream, but sends a RESV message back to the mobile node via the same new 
path Instead. The crossover RSVP router (i.e., node) is in both the old path (before 
the mobile node moved) and the new path between the mobile node and a 
destination node. 

Fig. 1 shows a block diagram of an example RSVP node according to an 
example embodiment of the present invention. An RSVP node according to the 
present invention may be any of many types of processing devices, e.g., a server, a 
router, or other computing device. As shown in Fig. 1 , RSVP node 10 may include a 
reservation module 12, a receiving module 14, a classification module 16, and a 
routing module 18. Each of these modules perform a particular function for the 
RSVP router, and may be composed of software, hardware, or a combination of 
software and hardware elements. Further, although shown as separate blocks in 
Fig. 1 , the function of one or all of these blocks may be included in one section of 
hardware or software or a combination thereof and still be within the spirit and scope 
of the present invention. Other modules or functionality may also exist in RSVP 
node 10. 

Reservation module 12 reserves resources for a flow in response to receipt of 
a message from a node. The node sending the message is normally a destination 



12 



017.39656X00 
17221 

node for the flow. For example, this message may be a RSVP message that is sent 
from a destination node back to the originating node. The RSVP message sets up 
and reserves resources in each of the RSVP nodes in the path between the 
originating node and the destination node. Receiving module 14 then receives the 
flow sent from the originating node. The flow may be comprised of one or more IP 
packets. The flow originates at the originating node and has a destination of a 
second node. The RSVP router sits somewhere in the path of the flow between the 
originating node and the destination node. 

Classification module 16 classifies the received flow based upon an address 
(home address) in the destination option header in the IP packets in the flow, if the 
address is present. The classification compares the home address with addresses 
stored to determine if the packets receive reserved resources previously setup for 
this particular flow from this home address. This insures that packets in the flow get 
the desired QoS. If there is no address in the destination option header, the RSVP 
node uses the address In the source IP address field of the packet to determine the 
quality of service for the packets. This may normally be a best effort quality of 
service. 

Routing module 18 routes the received flow using the reserved resources 
associated with the flow (if an address exists in the destination option header) based 
on the classification. These processes will be further illustrated using Fig. 2. 

Fig. 2 shows a diagram of a network where a mobile node is moved according 
to an example embodiment of the present invention. The network shown includes a 
mobile phone 30, multiple RSVP nodes 32-46, and a second (destination) node 48. 
Mobile node 30 desires to send a transfer of packets to second node 48 through the 
network. Initially, mobile node 30 sends a message to configure and establish a 
path through the network to the destination node 48. The path may include various 
RSVP nodes, as well as other possible nodes (not shown) In this example 
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embodiment, the RSVP nodes are RSVP routers. The message that sets up the 
path (or channel), e.g., PATH message, establishes a channel for sending the 
packets from mobile node 30 to node 48. Once node 48 receives this PATH 
message, node 48 responds in acknowledgment by sending a second message, 
e.g., a RSVP message, back through the established path to mobile node 30. The 
RSVP message traverses through the path and causes each RSVP node to reserve 
resources for the pending transfer from mobile node 30. Therefore, once the RSVP 
message is received by mobile node 30, a path has been established for sending a 
flow from mobile node 30 to node 48, as well as resources have been reserved in all 
RSVP nodes along the path which ensure that a flow sent via the path attains a 
desired quality of service. Mobile node 30 may now send a flow consisting of one or 
more packets to destination node 48 through the established path. 

As shown in Fig. 2, mobile node 30 has established a path through RSVP 
nodes 32, 34, 36 and 38 to destination node 48. When a RSVP node receives a 
flow, the RSVP node classifies the flow by looking at an address field or phone 
number in each packet. During classification, each RSVP node uses the address 
field in the packet header to determine if resources have been previously reserved 
for this flow on this RSVP node. Resources have been reserved in each RSVP node 
32, 34, 36 and 38 such that when these RSVP nodes receive packets with a source 
address identifying them from mobile node 30, these reserved resources are used to 
then continue to route the flow through the network. Packets that arrive at the RSVP 
nodes which have no resources reserved may be queued and routed when the node 
has the opportunity to route these packets. Therefore, these packets are given a 
best effort quality of service. Packets that have reserved resources are routed in a 
more timely fashion since resources have already been reserved to expedite the 
routing of these packets. These resources may include bandwidth resources, 
buffers, etc. 
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Although only RSVP nodes have been shown in Fig. 2 to illustrate the present 
invention, other nodes and or devices may exist in the path between mobile node 30 
and destination node 48, and between the various RSVP routers, for example, 
routers, switches, etc. and still be within the spirit and scope of the present invention. 
Further, other nodes, mobile or not, may be attached to the network. 

If mobile node 30 is moved from its first position in Fig. 2 to its second position 
in Fig. 2 (denoted by the arrow), a new path must be established to destination node 
48 for the current flow. Mobile node 30 sends a new PATH message through RSVP 
node 40 to RSVP node 42 and to RSVP node 36. This PATH message sets up a 
new path for the flow to from mobile node 30 to destination node 48 through RSVP 
nodes 40 and 42. 

As shown in Fig. 2, RSVP node 36 exists in the old path (i.e., from mobile 
node 30 through nodes 32, 34), and the new path (from mobile node 30 through 
nodes 40, 42). Therefore, RSVP node 36 may be called a crossover node since it 
resides at the intersection of the old path and a new path. In methods and apparatus 
according to the present invention, the PATH message sent from mobile node 30 
may only propagate upstream until it reaches a crossover point where an existing 
reservation already exists (i.e., RSVP node 36). The crossover RSVP node may not 
forward the PATH message further upstream since reservations from this point 
forward in the path still already exist for this current flow. Crossover RSVP node 36 
responds to the PATH command by sending a RSVP message back through RSVP 
nodes 42 and 40 to mobile node 30. This RSVP message causes RSVP nodes 42 
and 40 to establish reserved resources for the flow from mobile node 30. 

Since mobile node 30 has moved, the mobile node may now be in a new 
subnetwork location. In this case, mobile node 30 is given a new care of address. 
Normally, when the PATH message is sent from mobile node 30 with the new care of 
address and is received by RSVP node 36, RSVP node 36 may not associate this 
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address with the reserved resources for the flow since the care of address does not 
match the home address of mobile node 30 used to set up the original path and 
reserved resources. However, according to the present invention, the home address 
of mobile node 30 is present in a destination option header of each packet. RSVP 
nodes are configured to check this destination option header first when receiving a 
packet. Thus, when RSVP node 36 receives the path message from mobile node 
30, RSVP node 36 notes the home address of mobile node 30 in the destination 
option header of each packet and associates the reserved resources with this flow 
from mobile node 30. 

Once the path and reserved resources have been set up in RSVP node 40 
and 42, mobile node 30 may now continue sending the flow from mobile node 30 to 
node 48 through new path, RSVP nodes 40, 42 and 36 and 38. The present 
invention is advantageous since the path command need not travel the full length of 
the path but only need travel to a crossover node. Thus, signal processing delay is 
reduced, network load is decreased, and data packets corresponding to the specific 
flow need not be handled as best effort traffic while adjusting to the new care of 
address for mobile node 30, but continue to receive the desired quality of service 
after mobile node 30 changes its location and IP address. 

Fig. 3 shows a diagram of a network during tear down of an old path 
according to an example embodiment of the present invention. RSVP node 36, in 
addition to sending an RSVP message to mobile node 30 through RSVP nodes 40 
and 42 to establish reserve resources for the new path, also sends a message to 
RSVP nodes 34 and 32 that were part of the original path. This message, i.e., 
RESVTEAR message, causes RSVP nodes 34 and 32 to release the reserved 
resources for the flow that was traveling through the old path. The RESVTEAR 
message may be propagated from RSVP node 34 to RSVP node 32. It may be 
propagated until it reaches mobile node 30 whereby mobile node 30 may discard this 
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message which was destined to its old care of address. Therefore, RSVP nodes 32 
and 34 may release the resen/ed resources, allowing the resources to be reallocated 
to other flows that may be received. This saves resources in that once mobile node 
30 has moved to an established a new path, previously reserved resources are not 
continually reserved and not used. 

Fig. 4 shows a diagram of a network with efficient handoffs according to an 
example embodiment of the present invention. As shown in Fig. 4, according to the 
present invention, to improve the efficiency of handoff when a mobile node moves 
from one location to another, the mobile node may not only send a binding update, 
but also a RSVP message called "CA_ADV" (Care of Address Advertisement). A 
binding update may be sent from mobile node 30 to correspondent node 48. This 
notifies correspondent node 48 that mobile node 30 has moved. The CA_ADV 
RSVP message contains information that allows identification of the ongoing 
session. The CA_ADV message may be transported to the first RSVP node that is 
aware of this session (i.e., crossover RSVP node 36). The CA_ADV message may 
also be sent all the way to correspondent node 48. The CA_ADV message triggers 
a mapping between the home address and the new care of address of mobile node 
30 in each RSVP router in the new path (i.e., RSVP nodes 40, 42, 36 and 38). In the 
case of RSVP routers in the old and the new path, the CA_ADV message triggers a 
re-mapping between the home address and the new care of address of mobile node 
30. 

At the first RSVP node which is aware of the session, RSVP node 36, the 
CA_ADV message triggers an immediate PATH refresh towards the mobile node's 
new care of address. Concurrently with the PATH refresh, a RESV_TEAR message 
may be sent towards mobile node 30's old care of address, that removes the 
reservation on the old path (i.e., RSVP nodes 34, 32), that is no longer needed. A 
PATH message may also be sent from crossover RSVP node 36 to correspondent 
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node 48 concurrently with the sending of the RESV_TEAR message towards mobile 
node 30's old care of address. When the PATH message triggered by the CA_ADV 
RSVP message is received by mobile node 30, a RESV message may then be 
issued to reserve the resources on the new path between mobile node 30 and RSVP 
crossover node 36. 

This is advantageous in that the reservation on the new path between mobile 
node 30 and correspondent node 48 is set up after one and one half round trip times 
between mobile node 30 and RSVP crossover node 36, as opposed to one and one 
half round trip times between mobile node 30 and correspondent node 48. 
Considering the importance of improving handoff performance, this is a significant 
improvement. For example, the round trip time between mobile node 30 and 
correspondent node 48 may be 200 ms, while the round trip time between mobile 
node 30 and crossover RSVP node 36 may be 50 ms. This implies a QoS setup 
time of 300 ms for current solutions, as opposed to 75 ms according to the present 
invention. The performance improvement in handoff is easily noticeable for a user. 

In another embodiment of the present invention, a "Care of Address 
Advertisement" (CAA) object may be included in every PATH message sent by an IP 
node (e.g., RSVP router). The CAA object only needs to contain the home address 
and the new care of address of the mobile node. When a RSVP node receives a 
PATH message with a CAA object, one of two results may occur. 

First, when a RSVP node receives a PATH message with a CAA object and 
does not have a path state established for the flow, the RSVP node establishes a 
new path state including the mapping between the home address and the careof 
address. 

Secondly, when a RSVP node receives a PATH message with a CAA object 
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and the RSVP node has a path state for the flow, either: (1 ) if the path state shows 
that the mapping between the home address and the careof address has been 
changed, the path state is updated using the new mapping carried in the CAA object, 
and the PATH message is forwarded to the next hop; or (2) if the path state shows 
that the mapping between the home address and the careof address hasn't been 
changed, the mapping information in the path state does not need to be changed. 
Whether or not the PATH message is forwarded depends on the rules defined in the 
current RSVP. 

According to this embodiment of the present invention, the RSVP daemon 
doesn't need to get the careof address of the mobile node from the IP stack every 
time it receives a packet carrying a RSVP message, but just uses the information 
provided by the CAA object. In addition, the classification rule (i.e., whether to use 
the source address of the packet or home address in the home address option) can 
only be relied on if a "home address to careof address" mapping state has been 
established for the flow. This provides more efficient classification of received 
packets. 

Methods and apparatus according to the present invention are advantageous 
in that they enable RSVP to work with mobile IP. Efficiency is improved because 
one doesn't have to set up end to end RSVP reserved resources whenever a mobile 
node moves. Network load is also decreased because a PATH command message 
does not have to be forwarded to the end of the path, but only to a crossover node. 
Moreover, resources are saved due to the tear down of the old path. 

It is noted that the foregoing examples have been provided merely for the 
purpose of explanation and are in no way to be construed as limiting of the present 
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invention. While the present invention has been described with reference to a 
preferred embodiment, it is understood that the words which have been used herein 
are words of description and illustration, rather than words of limitation. Changes 
may be made within the purview of the appended claims, as presently stated and as 

5 amended, without departing from the scope and spirit of the present invention in its 
aspects. Although the present invention has been described herein with reference to 
particular methods, materials, and embodiments, the present invention is not 
intended to be limited to the particulars disclosed herein, rather, the present 
invention extends to all functionally equivalent structures, methods and uses, such 

10 as are within the scope of the appended claims. 
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